The following abbreviations are herewith defined, at least some of which are referred to within the following description of the prior art and the present invention.
AAAAuthentication, Authorization and AccountingCASCustomer Administration SystemCDCCollision Detection CounterCSCircuit SwitchedDITDirectory Information TreeDNDistinguished NameFEFront EndEMAEricsson Multi ActivationGSMGlobal System for Mobile CommunicationsHLRHome Location RegisterHSSHome Subscriber ServerITInformation TechnologyLDAPLightweight Directory Access ProtocolMAPMobile Application PartNDCNumber of Collisions to DetectPSPacket Switched
In the communications field, the current subscriber database architecture is being challenged by an upcoming architecture from mainstream IT technology where subscriber data is kept in one or more databases separated from the nodes giving the specific service. This approach is called a multi-tier architecture and an exemplary drawing which graphically illustrates this type of architecture being used in the wireless telecommunications communications field is shown in FIG. 1.
Referring to FIG. 1, there is illustrated a communications network 100 which has an IMS network 101 including a HSS FE 102 and a provisioning FE 104 and a CS/PS core network 106 including a HLR/AuC FE 108 and an AAA FE 110. The HSS FE 102, the provisioning FE 104, the HLR/AuC FE 108 and the AAA FE 110 all interface with a centralized database 112 which may be coupled to a EMA 114 (e.g., subscription provisioning device) which in turn is coupled to a conventional CAS 116. The IMS network 101 and the CS/PS core network 106 etc. include more components than the ones shown here but for clarity only the components that are relevant to the present discussion have been described herein.
This multi-tier architecture provides several advantages, not the least of which is cheaper scalability in the service logic tier or the ability to consolidate subscriber data so that subscriber administration is easier and less expensive when compared to traditional mobile communication networks. In this multi-tier architecture, the traditional monolithic nodes (including both data and processing logic) such as the HSS, the HLR and the AAA have evolved to be processing front-ends (FE) like the HSS FE 102, the provisioning FE 104, the HLR/AuC FE 108 and the AAA FE 110 while the data now resides in the centralized database 112 or in a distributed database accessible to the above front-ends 102, 104, 108 and 110.
In this multi-tier architecture, the HLR/AuC FE 108 (for example) after receiving some external event (i.e. a MAP message) from the CS/PS core network 106, has to read subscriber-related data from the centralized database 112, process that read data in view of the data received from the CS/PS core network 106, and depending on the result of this internal processing may want to modify the subscriber-related data that is currently stored within the centralized database 112. A detailed explanation about this process has been provided below with respect to FIG. 2 (PRIOR ART) where the centralized database 112 is a LDAP directory 112 and the HLR/AuC FE 108 is a LDAP client 108.
Referring to FIG. 2 (PRIOR ART), there is a signal flow diagram illustrating how a traditional LDAP client 108 reads data 202 from an entry in a traditional LDAP directory 112 (or LDAP server 112) and then modifies the data 202 which is stored within the entry of the traditional LDAP directory 112. The steps associated with where the client 108 reads and then modifies the data are as follows:    1a-1b. Read some data 202 from an entry (or entries) in the LDAP directory 112 that client 108 is interested in, for any purpose. This requires the client 108 to send one LDAP SearchRequest operation to the LDAP directory 112 (step 1a). The LDAP server 112 then sends a copy of the data 202 from the entry (or entries) using one or more LDAP SearchResponse answers (step 1b).    2. The client 108 may use application logic to process the read data 202 for any purpose, like for example, extracting information, processing the read data against some other internal data, sending the read data to another node/process, printing some results, evaluating some conditions . . . . In this case, client 108 has updated data 202′.    3a-3b. The client 108 wants to perform some updates on the data 202 held in the previously read entry (or entries) at the LDAP directory 112. This requires the client 108 to send one LDAP ModifyRequest operation with the updated data 202′ to the LDAP directory 112 (step 3a) (note: one LDAP ModifyRequest operation would be needed for each directory entry which is requested to be updated). The LDAP directory 112 updates the entry to have data 202′ and sends the client 108 a success message in an LDAP ModifyResponse (Result success) operation (step 3b). A single LDAP Modify operation only applies to the targeted entry, but can contain as many modification operations (add/delete/replace) as desired on the set of attribute types that are held in that particular entry.Unfortunately, if there are more than one or concurrent LDAP clients 102 and 108 (for example) that can interface with the LDAP directory 112, then a problematical situation as shown in FIG. 3 (PRIOR ART) may occur where the LDAP client 102 (client 2) overrides the data 202 that was previously read by LDAP client 108 (client 1) but was not yet modified by the LDAP client 108 (client 1). The steps are as follows:    1a. Client 1 requests to read some data 202 from the LDAP directory 112. This message could be a request to read any amount of data, and any standard LDAP SEARCH may be applicable and used to request the data 202.    1b. Client 1 receives the requested data 202 from the LDAP directory 112. This can be done by means of one or several LDAP messages (LDAP Search Result Entry), including a message to indicate that all requested information has been sent (LDAP Search Result Done). At this time, client 1 may take some time to perform any internal logic, for any purpose, like e.g. performing some consistency checks on the read data, connecting to another node to request some more data based on something read . . . . In this case, client 1 has updated data 202′.    2a. Client 2 requests to read some data 202 from the LDAP directory 112. This read message may request the same data as before, or part of the previously read data, or any other data within the LDAP directory 112. In this example, it is assumed that at least part of the same data 202 read in step 1b is requested by client 2.    2b. Client 2 receives the requested data 202 from the LDAP server 112. This can be done by means of one or several LDAP messages (LDAP Search Result Entry), including a message to indicate that all requested information has been sent (LDAP Search Result Done). Then, client 2 performs any required processing and logic, using or not using the read data for such purpose. In this case, client 2 has updated data 202″.    3a. Client 2 requests modification of some (at least one attribute) or all of the data 202 previously read by client 1.    3b. Client 2's modification request is successful. The modification was successfully performed, because the LDAP directory 112 does not have any reason/information to not allow this modification. From this moment on, the data 202 previously read by client 1 becomes obsolete, because at least a part of that data has been overwritten by client 2.    4a. Client 1 requests modification of the previously read data 202. In particular, client 1 requests to modify one or more of the attributes of the previously read data 202 that may have been totally or partially overwritten by client 2 during the previous step 3b.    4b. Client 1's modification request is a success and data 202′ is now stored in the LDAP directory 112. The LDAP directory 112 does not have any reason or information to not allow this particular modification of the data. However, it may happen that some modifications client 1 required, based on the data status at step 1b, may not still be valid. As a result, some data inconsistencies may appear.
In this particular case, it can be seen how data read by client 1 has been modified by client 2 before client 1 proceeds to update this data. This is not desirable. For example, if the updates on the data performed by client 1 are dependent on a service status to be “enabled”, then it may happen that client 2 has modified this service status to be “disabled” which means that the updates by client 1 would not have to be possible. This may end up in a failure due to wrong data updates. Thus, if a LDAP client (e.g., HLR/AuC FE 108) performs an LDAP Search, processes the LDAP response, and then sends modifications (LDAP Modify) to the LDAP directory 112. Then, there is no way today to assure that once the LDAP Modify is received, the same condition is still valid, since some modifications could have been performed on the LDAP directory 112 by another LDAP client (e.g., HSS FE 102) after the moment the LDAP Search was answered in response to the request from the first LDAP client. This situation may cause data inconsistencies. Accordingly, there is and has been a need to address this particular shortcoming and other shortcomings which is addressed by the present invention.